Sustainable Quality by Joseph Diele

Author:Joseph Diele
Language: eng
Format: epub
Publisher: Business Expert Press
Published: 2020-12-31T00:00:00+00:00

There are several different ways to trigger another MRR. Some examples would be:

• Design reviews

• Engineering changes to a product, software, assembly fixture, manufacturing process, packaging or the bill of materials (BOM)

• New testing software proposed for release

• New supplier to be added to approved vendor list (AVL)

Quality in Test Engineering

I stated previously in Chapter 1 that I believe it is incorrect to call a test function QA (short for quality assurance). It is very misleading in that it is such a narrow view of what the quality role should be inside of a company. But the term QA is so prevalent today, I do not expect that to change. Even though I feel QA as the only role for quality to be inadequate, that does not mean you can do away with testing. At least not until you have very mature development processes.

I have led many test groups throughout my career. But one particular development program stood out to me. This was at one of the larger companies I worked for, which happened to be very focused on total quality management (TQM) at the time. Early in the planning for this new product, I met with the head of the development team. I needed to put a test schedule together and was trying to estimate how many times we would need to go through our test suites before the product was ready to release. As we were meeting, we recalled that we found several issues in the previous generation product, as it moved from development to test (which was much improved from earlier generations where we found many issues after that transition). His response to me was, “Well, this time you won’t find any issues. We will make sure it is rock solid when it comes to you.” I’m glad I didn’t make a bet with him, because I would have lost. We really tried to beat up the product during our testing and it was in fact solid. I think we may have found one or two very minor issues, but nothing that required changes to the product or reasons for us to rerun our tests. Just to set the context for this accomplishment, the product was far from simple. This was the third generation of a very complex product that included hardware, robotics, storage, firmware, and management software. It remains my standard for what can be done when you design quality in from the start. As you might imagine, the product released on time (zero schedule slips), because we never had to go through that vicious cycle of “find and fix.”

I have always felt that testing needs to be tied to something. You need an anchor for your test development, so you don’t end of up with a collection of ad hoc tests. How do you know if you are adding good tests or bad ones?

The structured approach to testing that I have been very successful with is called requirement-based testing (RBT). Through this approach, we can clearly identify the functions and features of the product and how to best test them.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.